Wenn es um das Thema Observability geht, gibt es bei Modernen Frontends dieselben Herausforderungen wie bei verteilten Microservices-Architekturen. Dann oft laufen die Frontends als eigene Anwendungen im Browser (SPA-Architektur). Da es sich aber um die Benutzeroberfläche handelt, müssen noch zusätzliche Aspekte beachtet werden. Denn kommt es hier zu Rucklern, hohen Latenzen oder sogar Abstürzen, kommt das zwar bei den Nutzern negativ an, doch passendes Feedback dazu gibt es oft nicht. Damit es am besten gar nicht erst so weit kommt, sollte Observability auch im Frontend von Anfang an bedacht werden.

Die zunehmende mobile Nutzung geht beispielsweise mit unzuverlässigen und teilweise sehr langsamen Mobilfunkverbindungen, aber auch mit Endgeräten mit deutlich weniger Leistung als einem Desktop-PC einher.

Erschwerend kommt hinzu, dass Anwender zunehmend komfortable und dynamische Anwendungen erwarten. Das erhöht die Komplexität in der Entwicklung und kann zu schwer zu findenden Performanceproblemen führen. Auch kleine Erweiterungen oder Änderungen am Featureset wirken sich in der Regel auf dem Komponentenbaum und den Anwendungs-State aus. Manchmal ergeben sich daraus unvorhergesehene Wechselwirkungen, die nicht unbedingt zur Entwicklungszeit offensichtlich werden. Umso wichtiger ist es, bereits früh im Lebenszyklus einer Anwendung entsprechende Metrikdaten aus automatischen und reproduzierbaren Abläufen aufzuzeichnen und auszuwerten. Damit lassen sich Probleme und Regressionen frühzeitig erkennen und behandeln.

Werfen wir zunächst einen Blick auf den grundsätzlichen Aufbau einer Browseranwendung, um daraus abzuleiten, welche Metriken potenziell relevant sein können.

Aufbau einer Single-Page-Anwendung (SPA)

Aller Anfang sind in der Regel fachliche Anforderungen. Klassisch nach Jacobson [1] kann dazu ein Anwendungsfall (Use Case) oder als modernere Variante die User Story dienen. Diese in sich abgeschlossenen Aktivitäten können gut als Vorlage dienen, um damit Testszenarien zu entwickeln. Diese Szenarien können dann genutzt werden, um in der Build-/Integrationstestphase Metriken aufzuzeichnen, die dem Use Case zugeordnet werden. Für alle Use Cases können dann Trends aufgezeichnet und ausgewertet werden. Damit ist bei Regressionen schnell klar, welche Funktionalität betroffen ist bzw. an welchen Stellen noch Optimierungspotenzial besteht. Optimalerweise ist damit auch die Ursache bereits zu identifizieren. Doch dazu gleich mehr.

Auf oberster Ebene teilt sich eine Browseranwendung in verschiedene Routen auf. Während bei klassischen Webseiten jeder Routenwechsel zu einem vollständigen Neuladen der Seite und allen damit verbundenen Logiken (CSS, JavaScript, HTML) führte, können moderne Anwendungen isolierte Teile der Seite austauschen und müssen damit deutlich weniger Arbeit leisten.

Je nach verwendetem Framework gibt es ein Modulkonzept. Aus einem oder mehreren Modulen setzt sich die Anwendung bzw. eine Route dann zusammen. Ein Modul kann beispielsweise bei Angular nachträglich (lazy) geladen werden, was die initiale Ladezeit der Anwendung reduziert. Als Granularitätsebene wird dabei in der Regel eine Route oder Unterroute gewählt.

Auf unterster Ebene befinden sich dann Komponenten und Direktiven, die dazu dienen, eine Ebene der Wiederverwendung und Strukturierung zu bieten. Komponenten und Direktiven werden typischerweise im DOM der Webseite eingebunden und interagieren mit anderen Komponenten oder dem umgebenden DOM. Dabei kann Logik durch die Komponente selbst ausgeführt werden, auch der Browser muss potenziell CSS-Anweisungen ausführen und möglicherweise die Seite neu layouten. Als Reaktion darauf können wiederum andere Komponenten reagieren und zu weiteren Verarbeitungen führen. Dieser Prozess wird Rendering genannt. Damit die Anwendung auch etwas Sinnvolles leistet, wird noch Kommunikation mit dem Backend bzw. ein API benötigt. Diese Funktionalität wird bei Angular häufig in einem Service als Strukturelement implementiert und der von Angular bereitgestellte HttpClient verwendet. Bei anderen Frameworks wird häufig Axios als Client eingesetzt.

In diesem kurzen Abriss sind wir an wichtigen potenziellen Metrikpunkten vorbeigekommen:

• Initiale Bundle Size der Anwendung, wie viel muss minimal heruntergeladen werden?

• Ladezeit der Anwendung, ggf. heruntergebrochen in spezifische Untermetriken

• Zeit zum Wechsel einer Route

• Zeit für Rendering von Komponenten

• Antwortzeit bei HTTP-Anfragen

• Zeit für CSS-Auswertung

• Zeit für DOM-Manipulation

• Zeit für JavaScript-Ausführung und Garbage Collection

Aber Metriken sind nicht alles: Im Fehlerfall sollten Informationen zu den Schritten, die zu dem Problem geführt haben, aufgezeichnet werden. Durch Entwickler vorgesehene Protokollierungen (Logging) können auch im Frontend relevant sein und zur Observability beitragen. Genauso wie Protokollierungsinhalte sind Fehlermeldungen (Crash Reports) aufgrund der im Client laufenden Anwendungen zunächst nur lokal verfügbar und müssen zur dauerhaften Speicherung und Auswertung zu einem entsprechenden System durch ein Remote API transportiert werden.

Schauen wir uns einmal an, welche Werkzeuge existieren, um Daten im Frontend zu erheben und zu verarbeiten.

Zollstock und Stoppuhr

Zunächst einmal bieten moderne Browser APIs an, um Performanceinformationen [2] und Informationen zur Art der verwendeten Netzwerkverbindung [3] zu liefern. Die Unterstützung und der Reifegrad variieren je nach Hersteller. Diese Low-Level-APIs eigenen sich daher primär dazu, als Basis für eine höherwertige Abstraktion zu dienen. Eine solche Bibliothek ist beispielsweise perfume.js [4]. Dabei ist perfume.js agnostisch zum System, das zur Sammlung und Auswertung verwendet wird. Man kann damit zum Beispiel ein Matomo [5] oder auch Google Analytics anbinden. Zur Vereinfachung der Integration gibt es wiederum Libraries, wie z. B. getanalytics [6], das direkte Integration für Segment.io mitbringt.

An dieser Stelle ist etwas Irritation möglich, schließlich sind Google Analytics oder auch Matomo Werkzeuge, deren Einsatzbereich klassisches Web-Analytics ist. Also Auswertung von Besucherquellen, Besucherfluss auf der Seite und Zielerreichung. Tatsächlich bieten diese Tools auch eine Form von Observability: Werden die geschäftlichen Ziele erreicht? Gibt es einen Unterschied zwischen Anwendungsvarianten (A/B-Test)? Hat sich das Verhalten schlagartig geändert, kann dies Hinweise auf auftretende Probleme liefern.

Alternativ können diese Daten auch zu einem eigenen Backend Endpoint eingeliefert werden, beispielsweise in einer Spring-Boot-Anwendung. Diese kann die Daten dann als Prometheus-Metriken wieder reexportieren. Dies stellt auch einen sehr schlanken Stack dar, mit dem jedoch auch nur begrenzte Auswertungen möglich sind: Zum einen ist eine Verknüpfung mit den Daten aus den anderen Bereichen Logging, Tracing und Crash Reporting nicht ohne weiteres möglich. Zum anderen fällt auch die Segmentierung der Daten, z. B. nach Endgerätetyp oder Nutzwert schwer: Prometheus ist nicht für Zeitreihen mit hoher Kardinalität konzipiert.

Speziell für die Performanceanalyse von Webseiten hat Google vor einiger Zeit die PageSpeed-Tools entwickelt. Daraus entwickelte sich Lighthouse [7], das sowohl als Browser-Plug-in als auch in einem Kommandozeilenmodus ausgeführt werden kann. Die Ergebnisse können als HTML-Report, CSV- oder JSON-Daten bereitgestellt werden. Als Erweiterung gibt es das Projekt Lighthouse CI [8]. Wie der Name bereits vermuten lässt, liegt der Fokus auf der CI Stage. Damit können dann zum Beispiel direkt für einen Pull Request die zugehörigen Performancedaten angezeigt werden. Zusätzlich werden über den optional selbst betreibbaren Dienst LHCI Server die Performancedaten im zeitlichen Verlauf bereitgestellt. Durch die spezialisierte Darstellung ist schnell ein guter Eindruck über Trends zu gewinnen. Wie Lighthouse CI mit Docker als Teil der Build Pipeline betrieben werden kann, wird in [9] vorgestellt.

Für das eigene Thema Crash Reporting gibt es verschiedene Werkzeuge. Eine besondere Rolle nimmt hier Sentry [10] ein, da es sowohl Open Source ist als auch mit Docker recht einfach auf eigener Infrastruktur betrieben werden kann. Da Sentry speziell für den Umgang mit Fehlern entwickelt wurde, werden wichtige Diagnoseinformationen gebündelt an einem Fehlerreport bereitgestellt: Was waren die letzten Aktivitäten, die zu dem Crash geführt haben? An welcher Stelle im Quellcode ist der Fehler aufgetreten? In welcher Umgebung mit welcher Programmversion und zu welcher Zeit trat der Fehler auf? Fehler werden dedupliziert und für die Aggregation wird die Frequenz des Auftretens visuell dargestellt.

Wer bisher noch nicht mit Sentry gearbeitet hat, der sollte auf jeden Fall einen Blick darauf werfen. Denn nicht erst im produktiven Einsatz, sondern bereits in der CI-Umgebung und bei manuellem Test durch Tester und Fachabteilung kann so schnell wertvolles Feedback bereitgestellt werden.

Spannend ist dabei die Weiterentwicklung der Werkzeuge. Sentry beispielsweise hatte stets zum Ziel, Fehlersituationen transparent zu machen und bei der Analyse zu unterstützen. Dabei waren in der Vergangenheit Fehler im Frontend nicht mit Fehlern im Backend korrelierbar. Dazu muss Sentry erkennen, dass diese beiden Fehler in Beziehung stehen: Damit ist man schon beim Thema Tracing angelangt. Und genau das wurde in Sentry inzwischen nachgerüstet. Dazu müssen Requests mit Korrelationsinformationen erweitert werden: Ein Trace – vergleichbar mit einer Anwendungssitzung – kann mehrere Requests benötigen, die wiederum weitere Requests veranlassen. Solche Requests und andere dediziert ausgezeichnete Verarbeitungsschritte werden Spans genannt. Zum Beispiel kann eine besonders wichtige und komplexe Komponente als ein Span im Tracing überwacht werden.

Zusätzlich nimmt Sentry noch eine Zusammenfassung mehrerer Spans zu einer Transaction vor. Eine Transaction wird automatisch abgeschlossen, wenn die Seite verlassen wird oder in einem längeren Zeitraum keine weiteren Spans erfasst werden. Sentry verfügt darüber hinaus auch über Messmöglichkeiten für Anwendungsperformance in Form von Mobile- und Web-Vitals durch fest vordefinierten Metriken.

Aus der anderen Richtung kommt Elastic APM bzw. RUM: Mit Ursprüngen im Bereich der Dokumentverarbeitung erweiterte sich Elasticsearch mit Logstash und Kibana zum ELK-Stack. Damit war dann die zentrale Verarbeitung von Logdaten geschaffen. Mit Elastic Beats kamen dann Metrikdaten dazu. Zusammen mit passender Instrumentierung ist Elastic APM eine Lösung für Application Performance Management im Backend. Dies wird durch Real User Monitoring, Elastic RUM, für das Frontend ergänzt. Mit allen Bausteinen zusammen erhält man eine Observability-Lösung, die allerdings in Bezug auf Fehlermanagement verglichen mit Sentry aktuell weniger Funktionalität liefert. Man merkt also deutlich, dass die Werkzeughersteller alle eine Vision in Richtung integrierter Observability-Lösung teilen und eine entsprechende Weiterentwicklung stattfindet. In diesem Zuge etablieren sich auch Standards bezüglich der Instrumentierung und APIs: OpenTelemetry [12] soll einen Industriestandard schaffen, um zum einen mehr Flexibilität zu schaffen, gleichzeitig den Aufwand bei der Integration und Instrumentierung zu reduzieren. Die Idee, lediglich einmal mit OpenTelemetry zu instrumentieren, die Daten durch einen zentralen OpenTelemetry Collector aufzunehmen und dann an verschiedene Zielsysteme weiterzureichen, funktioniert beispielsweise für Sentry aktuell nur bedingt. Zwar gibt es einen Sentry Exporter, jedoch werden durch OpenTelemetry weniger Daten bereitgestellt, als der eigene Collector von Sentry zur Verfügung stellen würde. Entsprechend stehen einige Funktionen in Sentry, z. B. Anzeige des Quellcodeausschnitts, in dem ein Fehler auftritt, dann nicht zur Verfügung. Für den vollen Funktionsumfang kommt man in dem Fall nicht um mehrfache Integration herum.

Alle für einen – oder eins für alles?

Es gibt noch wesentlich mehr Werkzeuge, die in diesem Artikel aus Platzgründen nicht vorgestellt werden. Doch bereits wird die Beantwortung der unweigerlich aufkommen Frage „Und was sollte man nun verwenden?“ schwierig. Lässt man zur Vereinfachung einmal die Fragen nach der Betriebskomplexität und möglichen Kosten für die verschiedenen Produkte außen vor, bleibt vor allem zu beurteilen, mit welchen Werkzeugen die gewünschten Auswertungen umgesetzt werden können. Zudem ist aus Nutzersicht die Verwendung von möglichst wenig unterschiedlichen Werkzeugen zu bevorzugen.

Die zu erzeugenden Auswertungen sollten dabei aus fachlichen Anforderungen hergeleitet werden. Dabei zählen Service Level Objectives (SLOs) als zu erreichende Latenzzeiten oder Durchsätze mit zu den wichtigsten Ergebnissen aus der Planungsphase. Um die Auswertung nach SLOs zu ermöglichen, werden Service Level Indicators (SLIs) bestimmt, die in der Regel durch Instrumentierung oder expliziten Programmcode als Messpunkte bereitgestellt werden.

Lassen sich die Auswertungen nicht vorab spezifizieren, gibt es weiterhin die Möglichkeit, rohe Eventdaten zur Auswertung zu sammeln. Im Prinzip kann man sich das wie ein Data Warehouse vorstellen, das im Nachhinein flexible Auswertungen unter technischen oder fachlichen Gesichtspunkten ermöglicht. Mit Werkzeugen wie Twilio Segment [13] ist es auch möglich, die Daten an mehrere Konsumenten weiterzuleiten. Die Überschneidung mit OpenTelemetry und dem Ansatz flexibler Dokumente in Elasticsearch liegt dabei wiederum auf der Hand.

Beispielszenario

Wie die Verwendung der Werkzeuge und Integration in eine SPA aussehen könnte, wird im Folgenden anhand einer sehr simplen Angular-Anwendung gezeigt. Starten wir mit den für das Frontend relevanten SLOs:

• Maximale Bundlegröße von 1 MB für das initiale Laden

• Anwendung ist in 95 Prozent der Fälle in weniger als 2 Sekunden geladen (Largest contentful paint)

• Maximal 1 Prozent Fehlerrate pro Stunde bei HTTP-Aufrufen

• Latenz in 95 Prozent der HTTP Requests besser als 200 ms

Für das Beispiel Fachlichkeit können durch Nutzer Bewertungen abgegeben werden. Daraus können Metriken hergeleitet werden:

• Anzahl abgegebener Bewertungen

• Durchschnitt der Bewertungen der letzten n Tage

Diese fachlichen Metriken können durchaus aus dem Backend bereitgestellt werden, wir betrachten sie an dieser Stelle daher nicht weiter.

Für das erste SLO könnte man auf die Idee kommen, einfach nur die Größe im Build zu prüfen, und den Build zu brechen, falls das Ziel nicht erfüllt ist. Tatsächlich ist das sogar im Angular CLI mit den Bundle Budgets bereits möglich. Damit gibt es jedoch kein SLI, das über die Zeit aufgezeichnet werden kann. Damit fehlt die Möglichkeit, rechtzeitig einen Trend zu erkennen und bei Bedarf gegenzusteuern. Die Bundlegrößen können durch die Dateigrößen im dist-Ordner bestimmt werden. Die Werte können dann z. B. in eine Zeitreihendatenbank eingeliefert werden. Bei Prometheus kann das über das Push Gateway geschehen, als Metriktyp passt ein Gauge am besten, als zusätzliches Label kann der Name des Bundles dienen.

Das zweite SLO kann als Teil der Build Pipeline durch LHCI abgebildet werden, z. B. wie in [9] skizziert. Neben der Auswertung durch den LHCI-Server kommt auch hier die zusätzliche Auswertung mit einer Zeitreihendatenbank in Betracht. So kann man alle Werte in einem einzelnen Dashboard bereitstellen.

Um die Daten nicht nur synthetisch zu messen, sondern mitzubekommen, was Nutzer für ein Erlebnis haben, müssen die Daten bei den Nutzern erhoben werden. Das kann sehr simpel z. B. mit perfume.js erfolgen, und dann können die Werte z. B. mit einem Prometheus-Histogramm ausgewertet werden. Die Granularität wird dabei natürlich gröber, sollte jedoch an dieser Stelle in Kombination mit LHCI ausreichend sein. Alternativ nutzt man an der Stelle Sentry, Elastic RUM oder ein vergleichbares Werkzeug.

Für das dritte SLO müssen HTTP-Anfragen auf Fehler geprüft und es muss auf Fehler reagiert werden. Hier reicht eine allein durch ein Backend bereitgestellte Metrik ebenfalls nicht aus: Fehler, die beispielsweise im Reverse-Proxy entstehen, würden möglicherweise übersehen. Auch hier kann man sehr simpel unterwegs sein und Fehler durch einen Prometheus Counter abbilden. Mit Sentry erhält man mehr Überblick: Fehler werden zusammengefasst, Stack-Trace und Quellcode-Snippets können bei der schnellen Analyse helfen. Ein Mittelweg wäre ein Werkzeug, das nicht so stark bei Fehlern ist, wie zum Beispiel Elastic RUM, wenn ansonsten bisher kein Sentry im Einsatz ist und die Anzahl von Betriebskomponenten nicht erweitert werden soll.

Bei dem vierten SLO geht es um die Messung der Latenz, bis eine HTTP-Anfrage bearbeitet ist. Wichtig ist, dass dies nicht nur die Backend-Zeiten beinhaltet, sondern auch Transportzeiten, beispielsweise über ein Funknetz. Diese Daten können in Angular durch einen Interceptor ermittelt werden. Der muss auch nicht komplett neu entwickelt werden, es gibt für OpenTelemetry bereits eine Implementierung [14]. Alternativ bietet Elastic RUM eine automatische Integration. Bei Sentry müssen dazu durch das API explizit Transactions gestartet und abgeschlossen werden.

Auch wenn es so erscheinen mag, als wenn die großen Lösungen sehr viel Overhead erzeugen – der Nutzen steckt in vielen Details. So unterstützen Sentry und Elastic RUM, beispielsweise als Verfahren zur Lastreduktion, Sampling. Dabei werden lediglich Stichproben und nicht sämtliche Events aufgezeichnet. Ebenfalls oft wichtig ist Data Scrubbing, dabei werden personenbezogene Daten (PII) oder andere sensible Inhalte maskiert.

Umsetzung mit Angular

Um ein Gefühl dafür zu vermitteln, wie die technische Umsetzung aussehen kann, werden verschiedene Observability-Werkzeuge in einer Angular-Anwendung eingebunden. Zum Einsatz kommen Lighthouse CI, Cypress, Sentry und Elastic RUM. Das Beispiel ist auch unter [15] abrufbar.

Lighthouse CI wird im Beispiel durch Docker bereitgestellt. In der Praxis sollten die Werte im zeitlichen Verlauf, z. B. durch einen LHCI-Server, bereitgestellt werden. Im Beispiel wird lediglich ein HTML-Report erzeugt. Der Report ist in Abbildung 1 zu sehen. Listing 1 zeigt die Ausgabe auf der Kommandozeile: Die Einzelwerte für Performance, Accessibility, Best Practices und SEO werden ausgegeben. Damit könnte der Build auch abgebrochen werden, wenn Schwellenwerte unterschritten werden.

Abb. 1: Resultat der Lighthouse-Analyse

./lighthouse/run.sh
...
Done running autorun.
LHCI performance:0.83 accessibility:1 best-practices:0.93 seo:0.92 pwa:0.3

Die zeitliche Messung fachlicher Fälle wurde durch Cypress-Tests umgesetzt. Auch wenn in der Dokumentation darauf hingewiesen wird, dass Cypress nicht für Performancetests gedacht ist, handelt es sich hierbei um einen validen Anwendungsfall: Wir führen zum einen keine Microbenchmarks durch, zum anderen kann durch geeignete Rahmenbedingungen, wie isolierte Ausführung auf einem dedizierten Server und Verwendung des Medianwerts von mehreren Ausführungen, die Varianz reduziert werden. Cypress kann die Ergebnisse im JUnit-XML-Format bereitstellen, sodass die Einzelzeiten maschinenlesbar auswertbar sind. Die Ausführung von Cypress erfolgt durch npm bzw. Angular CLI mit ng e2e –watch false. Das Ergebnis ist in Abbildung 2 zu sehen.

Abb. 2: Cypress-Testausgabe

Um Sentry zu evaluieren, ist es am einfachsten, einen kostenlosen Account bei der SaaS-Lösung von Sentry zu erstellen. Die Integration in das Beispielprojekt verwendet Sentry durch den Schalter useSentry in der environment.ts-Datei. Neben dem automatischen Tracing beim Laden von Seiten und Routen ist für die „Abgabe Bewertung“-Aktion eine exemplarische Instrumentierung für Sentry in Kombination mit dem ngrx-Store eingebaut, die den fachlichen Fall explizit macht. Dazu wurde eine Sentry Transaction verwendet. In Abbildung 3 stammt die Überschrift „add bewertung“ und rechts im Bild „transaction: add bewertung“ von dieser Quelle.

Abb. 3: Sentry-Trace-Analyse eines Klicks auf Bewertung hinzufügen

Für Elastic RUM ist der Start mit docker-compose in wenigen Minuten erledigt, ein entsprechendes Compose File befindet sich im Ordner elastic-apm und kann auf Linux-Maschinen in der Regel mit docker-compose up gestartet werden. Um Elastic APM mit RUM zu verwenden, ist der useSentry-Schalter in der environment.ts entsprechend auf false zu stellen. Für Elastic ist vergleichbar zu Sentry eine Instrumentierung vorhanden, die einen Span erzeugt. Das Ergebnis ist in Abbildung 4 zu sehen.

Abb. 4: Elastic-Trace-Analyse eines Klicks auf Bewertung hinzufügen

Generell lässt sich festhalten, dass Screenshots den Werkzeugen nicht gerecht werden: Der Nutzen entsteht gerade dadurch, sich durch verschiedene Sichten zu bewegen und dabei die relevanten Auswertungen zu erhalten. Ein Blick in das Beispielprojekt ist daher ratsam.

Fazit und Ausblick

Man erkennt, wie sich die Herausforderungen zwischen Observability in Frontend und serverseitigen Anwendungen unterscheiden: Während bei Serveranwendungen die Umgebung durch I/O-Last, CPU, Speicher und Zugriffe auf Umsysteme dominiert wird, sind im Frontend durch den zum Einsatz kommenden Webbrowser andere Einflüsse gegeben. Dazu kommt der schwierigere Zugriff auf die Informationen, schließlich ist die Kontrolle über den Browser eingeschränkt und Kommunikation erfolgt stets per Netzwerk.

Es gibt zunehmenden Wettbewerb der Anbieter von Werkzeugen für Observability. Die Ansprüche von Nutzern und Entwicklern steigen stetig. Dem müssen Anwendungen, Frameworks und Werkzeuge gerecht werden. Wird rechtzeitig der Observability-Aspekt berücksichtigt, hält sich der Aufwand für den Einsatz auch im Frontend in Grenzen. Wird jedoch lediglich an klassische Unit-Tests gedacht, vielleicht noch mit einem manuellen Test vor einer Freigabe, besteht das Risiko, dass wichtige Informationen nicht zur Verfügung stehen und so unwissentlich der Geschäftserfolg gefährdet wird.

Für den Start reicht ein schlanker Stack aus. Ist für das Backend bereits Monitoring oder gar Observability-Infrastruktur vorhanden, kann dies in der Regel mitgenutzt werden. Wichtiger als die perfekte Technologie auszuwählen, ist es, sich frühzeitig mit dem Thema zu befassen und passende Auswertungen, SLOs und SLIs in Zusammenarbeit mit allen Stakeholdern zu definieren. Daraus können dann Anforderungen an die Werkzeuge und Umsetzung abgeleitet werden.